home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 8 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.7 KB  |  76 lines

  1. Path: chronicle.mti.sgi.com!news
  2. From: jonnyg@trojan.neta.com (J. Greenblatt)
  3. Newsgroups: comp.std.c++
  4. Subject: RTTI implementation...
  5. Date: 05 Jan 1996 19:32:45 GMT
  6. Organization: Internet Access, Chandler AZ.
  7. Approved: austern@mti.sgi.com
  8. Message-ID: <4ciauq$2e1@trojan.neta.com>
  9. Reply-To: jgreen@amex-trs.com
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. Summary: Make RTTI conditional by class.
  12. Keywords: RTTI
  13.  
  14.     I have been discussing RTTI with a person at work and have a
  15. suggestion I would like to share.
  16.  
  17. Problem:
  18.  
  19.     It seems that RTTI requires a compile time flag to be activated. When
  20. activated the code seems to bloat whether you actualy use the feature in the
  21. specific peice of code or not. From what I have learned this overhead is due
  22. to extra work done when the object is constructed (A pointer to this with a
  23. string representation of the class is added to a table). This overhead does
  24. not make RTTI a good addition to C++ but more of a optional addition to those
  25. who want it (this is how it is implemented now). Also are the addition of key
  26. words which is not a biggy in this case given the key word names.
  27.  
  28. Proposed solution:
  29.  
  30.     Allow RTTI to be implemented on the whole system as it is now and keep
  31. it as a option. In addition allow RTTI to be turned on on a class by class 
  32. basis. On a class by class basis RTTI would be enabled if a base of the 
  33. current class is declared with the RTTI keyword. The extra RTTI keywords 
  34. (dynamic_cast, static_cast, etc...) are only defined for classes declared 
  35. as RTTI classes. The RTTI overhead is now only felt when accessing objects
  36. of RTTI classes.
  37.  
  38. Example:
  39.  
  40.     // This is a non RTTI enabled class, no RTTI overhead, no RTTI keywords
  41.     class foo
  42.     {
  43.         int i;
  44.     };
  45.  
  46.     // This is a RTTI class with the RTTI overhead, RTTI keywords enabled.
  47.     RTTI class bar
  48.     {
  49.         int i;
  50.     };
  51.  
  52.     // This is also a RTTI class by inheritence
  53.     class baz: public bar
  54.     {
  55.        int k;
  56.     };
  57.  
  58. Conclusion:
  59.     I may have not considered all the issues here but I think the RTTI
  60. keyword would be a good way of using RTTI without being hit with the extra
  61. overhead when not needed. If the RTTI compiler option is used, all classes
  62. are RTTI classes whether RTTI is specified or not. Some vendors may want
  63. to experiment with it or add this capability as an extension to their
  64. compilers. If the RTTI keyword is used as an "extension", you could #define
  65. RTTI to be nothing on compilers that do not support it and turn the RTTI
  66. compiler flag making all classes RTTI, this will allow your code to be 
  67. portable accross compilers that do not support the conditional RTTI keyword.
  68.  
  69.     A lot of what I seen of RTTI is based on MicroSlof so other
  70. implementations or RTTI may or may not have the problems I described in
  71. the problem section.
  72.  
  73.                     JonG.
  74.  
  75.  
  76.